The following outlines implementation details of the new message header
 system, covering each of the headers supported by PCBoard v15.0:
|Last update: 04/27/93
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

 FROM
 ----
 For v15.0, this field allows a name that is longer than 25 characters to be
|stored in the message.  In order to ENTER a name that is longer than 25
|characters, however, the conference must have the "Allow Internet TO: Names"
|switch enabled.  Of course, the only way to edit the FROM field is to use
|the (E)dit Header command.

 If the message header FROM field is blank (all spaces) then PCBoard will
 display only the extended header FROM field.

 If the message header FROM field is not blank, then PCBoard will display
 the extended header FROM field, then a comma, then the message header FROM
 field.

|FROM2
|-----
|This field is only expected to exist if the FROM field is utilized first.
|It allows another 60 characters to be used for the FROM field.  PCBoard will
|automatically piece together the two FROM/FROM2 fields and will perform any
|wrapping on screen as necessary.

 TO
 --
 For v15.0, this field allows a name that is longer than 25 characters to be
 stored in the message.  PCBoard only allows a caller to type in a TO name
 longer than 25 characters if Internet style (long) addresses are enabled
 via PCBSetup.  This is done on a per-conference basis.

 If the message header TO field is blank (all spaces) then PCBoard will
 display only the extended header TO field.

 If the message header TO field is not blank, then PCBoard will display first
 the extended header TO field, then a comma, then the message header TO field.

|TO2
|---
|This field is only expected to exist if the TO field is utilized first.
|It allows another 60 characters to be used for the TO field.  PCBoard will
|automatically piece together the two TO/TO2 fields and will perform any
|wrapping on screen as necessary.

 SUBJECT
 -------
 If an alternate subject is supplied it will be displayed in the message
 header instead of the 25-character subject found in the main header.  If the
 caller replies to the message the alternate subject is automatically carried
 forward.

 ATTACH
 ------
 When saving the message the caller may attach a file by uploading it while
 in the editor.  PCBoard will use standard file transfer protocols to receive
 the file.  The filename will be stored in the header.  NO PATH information
 will be included.  PCBoard must be configured with each conference set to
 a separate file attachment subdirectory.  By not including the path
 information in the header, the files may be moved simply by changing the
 PCBoard configuration.  If a user reads the message through PCBoard he will
 be prompted to download the attached file.  If the user downloads the
 message through an offline mail reader then it is up to the mail door author
 to provide options for 'always' downloading the file, 'never' downloading
 the file, or provide the ability to call back later to pick the file up.

 The "Descript" field of the extended header will be formatted as follows:

    FILENAME.EXT (FILESIZE) UNIQUE.###

 The first filename is the actual name of the file that is being attached.

 The file size is the proper size of the file.

 The unique filename is the name which is used to STORE the file on disk.
 Because of the possibility of more than one message having the same name
 for a file attachment, it is necessary to use a unique storage name.
 PCBoard will display only the first filename and size to the caller.  But
 when the caller downloads the file, PCBoard will have to copy the stored
 name to the proper filename first, then perform the file transfer.

 PCBoard has implemented the unique filename by simply taking the original
 filename and changing the extension to ".000" for the first file by that
 name, ".001" for the second, ".002" for the third and so on.  In other
 words, when a caller uploads an attached file, PCBoard will check for any
 previously existing "FILENAME.000" file.  If one is found, then it will
 check for a "FILENAME.001" file and so on until a unique name can be
 posted.

 For offline mail doors, the door software will have to perform the same
 operation as PCBoard - ensuring that the file is posted in the proper
 directory and that it has a unique name.  The extended header MAY need
 to be updated before posting the message in the message base!

 LIST
 ----
 When writing a message it can sometimes be advantageous to send a single
 message to two or more individuals without:  1) making the message public,
 or 2) making separate copies of the message for each recipient.  When
 addressing the message the caller may indicate, by typing 'LIST' in the TO:
 field, that he or she desires that PCBoard prompt for a list of names to
 store in the extended header.  Each name entered is acted upon similar to
 the TO field described above.  Each name is stored in its own unique header
 with an initial Status byte of 'N'.  The message will be viewable only to
 those in the list and the sysop.  As each intended recipient reads the
 message the Status byte for the appropriate extended header will be changed
 to an 'R'.  WARNING:  Older mail doors will not know to set this byte.  The
 message could, in fact, be read by all users in the list, but not be flagged
 as having be read by all, unless the mail door(s) in use are properly
 updated to perform this function.  This merely means that PCBPack will not
 know to delete the message by seeing if the message has been read.  Instead,
 it will have to remove the message based on age or message number limits as
 set by the sysop.

 ROUTE
 -----
 PCBoard can prompt a caller for routing information if the sysop has
 configured it to do so.  A NETMAIL system that receives the message should
 verify that it was intended for the BBS that received it.   If the caller is
 replying to a message then ROUTE automatically receives the contents of the
 ORIGIN field, if one exists, and the caller is not prompted to enter the
 routing information.

 ORIGIN
 ------
 This field is filled in by PCBoard using a default specified in the PCBoard
 configuration IF the sysop has configured it to do so.  If an ORIGIN field
 is found, the NETMAIL software that is exporting the message may accept the
 default or it may modify it in a manner that is compatible with the NETMAIL
 package in case it is different from that used by PCBoard.

 The default ORIGIN field will be straight text which simply identifies the
 BBS system.  This is similar to the method used by PCRELAY software which
 uses a 7 (or is it 8?) character name to indicate the origin.  The length
 allowed by PCBoard for the ORIGIN line is the full 60 character limit of
 the extended header.

 To reiterate:  This scheme need not be used by the NETMAIL software.  The
 ORIGIN field may be replaced with one that is compatible with the NETMAIL
 software being used to echo a particular conference.  HOWEVER, where
 multiple netmail systems share a single conference it is highly desireable
 that the NETMAIL software be written to keep the origin intact and use some
 type of look-up table to determine any other necessary information.

 REQRR
 -----
 This packet indicates that the caller is requesting that a return receipt
 message be generated as soon as the message is received by the addressee.

 If the caller reads the message online (via PCBoard) then PCBoard will
 immediately generate a return message addressed to the TO field.  It will
 also use the extended header TO, SUBJECT, and ORIGIN information to get the
 message back to the originator.  The message generated will include an
 ACKRR to indicate that it is an acknowledgement.  No other information will
 be in the body of the message.

 The "Descript" field of the extended header, when generated by PCBoard,
 will say "Caller has requested a Return Receipt".  This will allow those
 using incompatible software to at least understand what is happening.

 PCBoard, when displaying the message to the caller, will indicate at the
 bottom of the message that the sender has requested a Return Receipt.  If
 this is the first time the message has been read then it will also indicate
 that the Return Receipt is being generated right then.

 ACKRR
 -----
 When a caller views an ACKRR message online (via PCBoard), PCBoard will use
 the current language (pcbtext file) to display the acknowledgement to the
 caller appropriately.  No other information in the body of the message will
 be shown to the caller.

 The "Descript" field of the extended header will be formatted as follows:

    "Acknowledge Receipt of msg ###### written on ##/##/## ##:##"

 PCBoard will read the Descript field and parse out the written on
 ##/##/## ##:## information.  If the reply message number is 0 then it
 will also use the "msg #####" portion.  Then, using the pcbtext file,
 it will display an appropriate message to the caller to indicate that
 the message he or she wrote on MM/DD/YY at HH:MM has been received.

 The FROM field of the message header will say "RETURN RECEIPT".  An
 ACKNAME header will will be included in to indicate the actual name of
 the caller having received the message.

 ACKNAME
 -------
 This field is used in conjuction with ACKRR to indicate the name of the
 user that received the message.

 PACKOUT
 -------
 This field holds a date in the form MM/DD/YY which specifies the date for
 when a message should be packed out.  As long as the message has not been
 killed, the message will remain in the message base until that date.

 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 question and Answer Section
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

 Q: With the long name and subject fields possible, what is going to happen
 to the header display in PCBoard when reading messages?

 A: The following is the proposed header display format:

 Date: 10-01-92 (01:01)            Number: 1100 of 1200 (Refer 1050)
   To: A very long name can be used here, ACCOUNT NAME
 From: From another long named user, ACCOUNT NAME
 Subj: A very long subject - mixed case is possible throughout
 Read: 08-15-92 (17:10)            Status: PUBLIC MESSAGE / FILE / LIST
 Conf: MAIN BOARD (0)           Read Type: GENERAL (+)

 The above example shows what a header might look like if the TO, FROM and
 SUBJECT fields were all replaced with extended header information.  It also
 shows what the header would look like if a file were attached and the
 message were addressed to a list of users (carbon copy list).

 Q: Where will attached files be stored?

 A: Each conference can be configured with a unique subdirectory for storing
 attached files.  The subdirectory need not be included in the DLPATH.LST
 file since PCBoard will be able to locate the file attachment.  However, it
 may be included in the DLPATH.LST if you want others, who are not reading
 the message, to be able to download the file if they know the name.

 Q: Will the full path of the attached file be stored in the message header?

 A: No.  By storing only the name of the file, the sysop may change the
 configuration at any time without having to process the message base to make
 the change.  In other words, the sysop could move attached files from one
 drive to another with a simple change in configuration.

 Q: Will protocol transfers be allowed for attached uploads?  How about the
 message text itself?

 A: Yes to both questions.  The user can upload message text using a transfer
 protocol other than ASCII.  If the message is to be saved with an attached
 file then the caller will be prompted for the upload and, again, a protocol
 transfer will take place.